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Abstract 

Functional reactive programming (FRP) has simple and powerful 
semantics, but has resisted efficient implementation. In particular, 
most past implementations have used demand-driven sampling, 
which accommodates FRP’s continuous time semantics and fits 
well with the nature of functional programming. Consequently, 
values are wastefully recomputed even when inputs don’t change, 
and reaction latency can be as high as the sampling period. 

This paper presents a way to implement FRP that combines 
data- and demand-driven evaluation, in which values are recom¬ 
puted only when necessary, and reactions are nearly instantaneous. 
The implementation is rooted in a new simple formulation of FRP 
and its semantics and so is easy to understand and reason about. 

On the road to a new implementation, we’ll meet some old 
friends (monoids, functors, applicative functors, monads, mor- 
phisms, and improving values) and make some new friends (func¬ 
tional future values, reactive normal form, and concurrent “unam¬ 
biguous choice”). 

Categories and Subject Descriptors D.1.1 \Software\: Program¬ 
ming Techniques—Applicative (Functional) Programming 

General Terms Design, Theory 

Keywords Functional reactive programming, semantics, concur¬ 
rency, data-driven, demand-driven 

1. Introduction 

Functional reactive programming (FRP) supports elegant program¬ 
ming of dynamic and reactive systems by providing first-class, 
composable abstractions for behaviors (time-varying values) and 
events (streams of timed values) (Elliott 1996; Elliott and Hudak 
1997; Nilsson et al. 2002). 1 Behaviors can change continuously 
(not just frequently), with discretization introduced automatically 
during rendering. The choice of continuous time makes programs 
simpler and more composable than the customary (for computer 
programming) choice of discrete time, just as is the case with 
continuous space for modeled imagery. For instance, vector and 
3D graphics representations are inherently scalable (resolution- 
independent), as compared to bitmaps (which are spatially dis¬ 
crete). Similarly, temporally or spatially infinite representations are 


1 See http: //haskell. org/haskellwiki/FRP for more references. 
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more composable than their finite counterparts, because they can be 
scaled arbitrarily in time or space, before being clipped to a finite 
time/space window. 

While FRP has simple, pure, and composable semantics, its ef¬ 
ficient implementation has not been so simple. In particular, past 
implementations have used demand-driven (pull) sampling of reac¬ 
tive behaviors, in contrast to the data-driven (push) evaluation typ¬ 
ically used for reactive systems, such as GUIs. There are at least 
two strong reasons for choosing pull over push for FRP; 

• Behaviors may change continuously, so the usual tactic of idling 
until the next input change (and then computing consequences) 
doesn’t apply. 

• Pull-based evaluation fits well with the common functional 
programming style of recursive traversal with parameters (time, 
in this case). Push-based evaluation appears at first to be an 
inherently imperative technique. 

Although some values change continuously, others change only 
at discrete moments (say in response to a button click or an object 
collision), while still others have periods of continuous change al¬ 
ternating with constancy. In all but the purely continuous case, pull- 
based implementations waste considerable resources, recomputing 
values even when they don’t change. In those situations, push-based 
implementations can operate much more efficiently, focusing com¬ 
putation on updating values that actually change. 

Another serious problem with the pull approach is that it im¬ 
poses significant latency. The delay between the occurrence of an 
event and the visible result of its reaction, can be as much as the 
polling period (and is on average half that period). In contrast, since 
push-based implementations are driven by event occurrences, reac¬ 
tions are visible nearly instantaneously. 

Is it possible to combine the benefits of push-based evaluation— 
efficiency and minimal latency—with those of pull-based evaluation— 
simplicity of functional implementation and applicability to tem¬ 
poral continuity? This paper demonstrates that it is indeed possible 
to get the best of both worlds, combining data- and demand-driven 
evaluation in a simple and natural way, with values being recom¬ 
puted only, and immediately, when their discrete or continuous 
inputs change. The implementation is rooted in a new simple for¬ 
mulation of FRP and its semantics and so is relatively easy to 
understand and reason about. 

This paper describes the following contributions: 

• A new notion of reactive values, which is a purely discrete sim¬ 
plification of FRP’s reactive behaviors (no continuous change). 
Reactive values have simple and precise denotational semantics 
(given below) and an efficient, data-driven implementation. 

• Decomposing the notion of reactive behaviors into independent 
discrete and continuous components, namely reactive values 
and (non-reactive) time functions. Recomposing these two no¬ 
tions and their implementations results in FRP’s reactive behav¬ 
iors, but now with an implementation that combines push-based 



and pull-based evaluation. Reactive values have a lazy, purely 
data representation, and so are cached automatically. This com¬ 
posite representation captures a new reactive normal form for 
FRP. 

Modernizing the FRP interface, by restructuring much of its 
functionality and semantic definitions around standard type 
classes, as monoids, functors, applicative functors, and monads. 
This restructuring makes the interface more familiar, reduces 
the new interfaces to learn, and provides new expressive power. 
In most cases, the semantics are defined simply by choosing the 
semantic functions to be type class morphisms (Elliott 2009). 

A notion of composable future values , which embody pure 
values that (in many cases) cannot yet be known, and is at 
the heart of this new formulation of reactivity. Nearly all the 
functionality of future values is provided via standard type 
classes, with semantics defined as class morphisms. 

Use of Warren Burton’s “improving values” as a richly struc¬ 
tured (non-flat) type for time. Events, reactive values, reactive 
behaviors, and future values can all be parameterized with re¬ 
spect to time, which can be any ordered type. Using improving 
values (over an arbitrary ordered type) for time, the semantics 
of future values becomes a practical implementation. 

A new technique for semantically determinate concurrency via 
an “unambiguous choice” operator, and use of this technique to 
provide a new implementation of improving values. 


2. Functional reactive programming 

FRP revolves around two composable abstractions: events and be¬ 
haviors (Elliott and Hudak 1997). Because FRP is a functional 
paradigm, events and behaviors describe things that exist, rather 
than actions that have happened or are to happen (i.e., what is, not 
what does). Semantically, a (reactive) behavior is just a function of 
time, while an event (sometimes called an “event source”) is a list 
of time/value pairs (“occurrences”). 

type B a = T -*■ a 

type E a = [( T, a)] — for non-decreasing times 

Historically in FRP, T = R. As we’ll see, however, the semantics 
of behaviors assumes only that T is totally ordered. The type T of 
occurrence times is T extended with — oo and oo. 

Orginally, FRP had a notion of events as a single value with 
time, which led to a somewhat awkward programming style with 
explicit temporal loops (tail recursions). The sequence-of-pairs for¬ 
mulation above, described in, e.g., (Elliott 1998a; Peterson et al. 
1999) and assumed throughout this paper, hides discrete time it¬ 
eration, just as behaviors hide continuous “iteration”, resulting in 
simpler, more declarative specifications. 

The semantic domains B a and E a correspond to the behavior 
and event data types, via semantic functions: 

at :: Behavior a —> B a 

occs :: Event a —> E a 

This section focuses on the semantic models underlying FRP, 
which are intended for ease of understanding and formal reasoning. 
The insights gained are used in later sections to derive new correct 
and efficient representations. 

FRP’s Behavior and Event types came with a collection of 
combinators, many of which are instances of standard type classes. 
To dress FRP in modem attire, this paper uses standard classes and 
methods wherever possible in place of names from “Classic FRP”. 


2.1 Behaviors 

Perhaps the simplest behavior is time, corresponding to the identity 
function. 

time :: Behavior Time 
at time = id 

2.1.1 Functor 

Functions can be “lifted” to apply to behaviors. Classic FRP 
(CFRP) had a family of lifting combinators: 

lift n :: (ai - ... - a n - 6) 

—> (Behavior oi —> ... —> Behavior a n —^ Behavior b) 
Lifting is pointwise and synchronous: the value of lift n f hi ...b„ at 



at ( lift n f bi ... b„) = A t^f (6i l at‘ t )... (b n ‘at‘ t ) 

The Functor instance for behaviors captures unary lifting, with 
fmap replacing FRP’s lift 1 . 

fmap :: (a —^ b) —+ Behavior a —* Behavior b 
The semantic domain, functions, also form a functor: 
instance Functor ((—>) t) where 
fmap f g= fog 

The meaning of fmap on behaviors mimics fmap on the meaning 
of behaviors, following the principle of denotational design using 
type class morphisms (Elliott 2009) and captured in the following 
“semantic instance”: 3 

instance sem Functor Behavior where 
at (fmap f b) = fmap f (at b) 

= f o at b 

In other words, at is a natural transformation, or “functor mor¬ 
phism” (for consistency with related terminology), from Behavior 
to B (Mac Lane 1998). 

The semantic instances in this paper (“instance S em ...”) 
specify the semantics, not implementation, of type class instances. 

2.1.2 Applicative functor 

Applicative functors (AFs) are a recently explored notion (McBride 
and Paterson 2008). The AF interface has two methods, pure and 
(<*>), which correspond to the monadic operations return and 
ap. Applicative functors are more structured (less populated) than 
functors and less structured (more populated) than monads, 
infixl 4 <*> 

class Functor f => Applicative f where 
pure :: a —> f a 
(<*>)::/(a -6)-/ a -/ b 
These two combinators suffice to define liftA 2 , liftA 3 , etc. 

infixl 4 <$> 

(<$>) :: Functor f => (a —> b) —> f a —> f b 
f <$> a = fmap f a 
liftA 2 :: Applicative f =4- (a —*• 6 —> c) 
—>fa—>fb—>fc 
liftA 2 f a b = f <S£> a <*> b 


2 Haskellism: The at function here is being used in both prefix form (on the 
left) and infix form (on the right). 

3 Haskellism: Function application has higher (stronger) precedence than 
infix operators, so, e.g., / o at b = f o (at b). 




liftA 3 :: Applicative / => (a —> b ^ c ^ d) 

-/ a^fb^fc^fd 
liftA s f a li ft A 2 f a b<*>c 

The left-associative (<$>) is just a synonym for fmap —a stylistic 
preference—while liftA 2 , liftA 3 , etc. are generalizations of the 
monadic combinators liftM 2 , liftM 3 , etc. 

CFRP’s lift 0 corresponds to pure, while lift 2 , lift 3 , etc corre¬ 
spond to liftA 2 , liftA 3 , etc., so the Applicative instance replaces 
all of the lift n . 4 

Functions, and hence B, form an applicative functor, where 
pure and (<*>) correspond to the classic K and S combinators: 
instance Applicative ((—*•) t) where 
pure = const 
f <*> g = A< -> (/ t) (g t) 

The Applicative instance for functions leads to the semantics 
of the Behavior instance of Applicative. As with Functor above, 
the semantic function distributes over the class methods, i.e., at is 
an applicative functor morphism: 

instance S em Applicative Behavior where 
at (pure a) = pure a 
= const a 

at (bf <*> b x ) = at bf <*> at b x 

= \t —> (bf ‘at't) (b x 'at't) 

So, given a function-valued behavior bf and an argument-valued 
behavior b, , to sample bf <*> b x at time t, sample bf and b x at t 
and apply one result to the other. 

This (<*>) operator is the heart of FRP’s concurrency model, 
which is semantically determinate, synchronous, and continuous. 

2.1.3 Monad 

Although Behavior is a semantic Monad as well, the implemen¬ 
tation developed in Section 5 does not implement Monad. 

2.2 Events 

Like behaviors, much of the event functionality can be packaged 
via standard type classes. 

2.2.1 Monoid 

Classic FRP had a never-occurring event and an operator to merge 
two events. Together, these combinators form a monoid, so 0 and 
(©) (Haskell’s mempty and mappend) replace the CFRP names 
neverE and (.|.). 

The event monoid differs from the list monoid in that (©) must 
preserve temporal monotonicity. 

instance sem Monoid (Event a) where 
occs 0 =[] 

occs (e © e') = occs e 'merge' occs e' 

Temporal merging ensures a time-ordered result and has a left-bias 
in the case of simultaneity: 
merge :: E a —> E a —> E a 

'merge' vs = vs 
us 'merge' [] = us 

(( t a , a) : ps) 'merge' ((it,, b) : qs) 

| t a ^ h = (t a , a) : (ps 'merge' ((it,, b) : qs)) 

| otherwise = (it,, b) : (((i a , a) ’■ ps ) 'merge' qs) 

Note that occurrence lists may be infinitely long. 

4 The formulation of the lift n in terms of operators corresponding to pure 
and (<*>) was noted in (Elliott 1998a, Section 2.1). 


2.2.2 Functor 

Mapping a function over an event affects just the occurrence values, 
leaving the times unchanged. 

instance sem Functor Event where 

occs (fmap f e) = map (\(i a , a) -*■ (t a ,f a)) (occs e) 

2.2.3 Monad 

Previous FRP definitions and implementations did not have a 
monad instance for events. Such an instance, however, is very 
useful for dynamically-generated events. For example, consider 
playing Asteroids and tracking collisions. Each collision can break 
an asteroid into more of them (or none), each of which has to be 
tracked for more collisions. Another example is a chat room hav¬ 
ing an enter event whose occurrences contain new events like speak 
(for the newly entered user). 

A unit event has one occurrence, which is always available: 
occs (return a) = [(—oo, a)] 

The join operation collapses an event-valued event ee: 
join E :: Event (Event a) —> Event a 
Each occurrence of ee delivers a new event, all of which get merged 
together into a single event. 
occs (join E ee) = 

foldr merge [] o map delay Occs o occs ee 
delayOccs :: (T, Event a) —> E a 

delay Occs (t e , e) = [(t e 'max' i a ,a) \ (t a , a) <— occs e] 
Here, delayOccs ensures that inner events cannot occur before they 
are generated. 

This definition of occs hides a subtle problem. If ee has in¬ 
finitely many non-empty occurrences, then the foldr, if taken as 
an implementation, would have to compare the first occurrences of 
infinitely many events to see which is the earliest. However, none 
of the occurrences in delayOccs (i e , e) can occur before time 
t e , and the delayOccs applications are given monotonically non¬ 
decreasing times. So, only a finite prefix of the events generated 
from ee need be compared at a time. 

2.2.4 Applicative functor 

Any monad can be made into an applicative functor, by defining 
pure = return and (<*>) = ap. However, this Applicative 
instance is unlikely to be very useful for Event. Consider function- 
and argument-valued events e/ and e x . The event e/ <*> e x would 
be equivalent to e/ 'ap' e x and hence to 
ef »= A/ —> e x »= Xx —> return (} x) 
or more simply 

ef >= Xf —> fmap f e x 

The resulting event contains occurrences for every pair of occur¬ 
rences of e/ and e x , i.e., (if ‘max' i x ,f x) for each (if,f) € 
occs ef and (i x ,x) €. occs e x . If there are m occurrences of e/ 
and n occurrences of e x , then there will m x n occurrences of 
ef <*> e x . Since the maximum of two values is one value or the 
other, there are at most m+n distinct values of tf ‘max' t x . Hence 
the m x n occurrences must all occur in at most m + n tempo¬ 
rally distinct clusters. Alternatively, one could give a relative time 
semantics by using (+) in place of max. 

2.3 Combining behaviors and events 

FRP’s basic tool for introducing reactivity combines a behavior and 




switcher :: Behavior a —> Event (Behavior a) 

—> Behavior a 

The behavior bo ‘ switcher ‘ e acts like &o initially. Each occurrence 
of the behavior-valued event e provides a new phase of behavior 
to switch to. Because the phases themselves (such as bo) may be 
reactive, each transition may cause the switcher behavior to lose 
interest in some events and start reacting to others. 

The semantics of bo 1 switcher 1 e chooses and samples either 6 0 
or the last behavior from e before a given sample time t: 

(bo ‘ switcher‘ e) ‘at 1 t = last (bo : before (occs e) t) ‘at‘ t 

before :: E a —> T —> [a] 

before os t = [a \ (i a , a) <— os, i a < t] 

As a simple and common specialization, stepper produces 
piecewise-constant behaviors (step functions, semantically): 

stepper :: a —> Event a —> Behavior a 

ao ‘ stepper ‘ e = pure ao ‘switcher ‘ (pure <S5> e) 

Hence 

at (ao ‘stepper ‘ e) = At —> last (ao : before (occs e ) t) 

There is a subtle point in the semantics of switcher. Consider 
bo ‘stepper ‘ (e © e'). If each of e and e' has one or more occur¬ 
rences at the same time, then the ones from e' will get reacted to 
last, and so will appear in the switcher behavior. 

3. From semantics to implementation 

Now we have a simple and precise semantics for FRP. Refining it 
into an efficient implementation requires addressing the following 
obstacles. 

• Event merging compares the two occurrence times in order to 
choose the earlier one: t a ^ 4. If time is a flat domain (e.g., 
Double), this comparison could not take place until both t a and 
h are known. Since occurrence times are not generally known 
until they actually arrive, this comparison would hold up event 
reaction until the later of the two occurrences, at which time 
the earlier one would be responded to. For timely response, the 
comparison must complete when the earlier occurrence hap¬ 
pens. 5 Section 4 isolates this problem in an abstraction called 
“future values”, clarifying exactly what properties are required 
for a type of future times. Section 9 presents a more sophisti¬ 
cated representation of time that satisfies these properties and 
solves the comparison problem. This representation adds an ex¬ 
pense of its own, which is removed in Sections 10 and 11. 

• For each sample time t, the semantics of switcher involves 
searching through an event for the last occurrence before t. This 
search becomes costlier as t increases, wasting time as well 
as space. While the semantics allow random time sampling, in 
practice, behaviors are sampled with monotonically increasing 
times. Section 8 introduces and exploits monotonic time for 
efficient sampling. 

• The semantics of behaviors as functions leads to an obvious, but 
inefficient, demand-driven evaluation strategy, as in past FRP 
implementations. Section 5 introduces a reactive normal form 
for behaviors that reveals the reactive structure as a sequence 
of simple non-reactive phases. Wherever phases are constant (a 
common case), sampling happens only once per phase, driven 
by occurrences of relevant events, as shown in Section 8. 


5 Mike Sperber noted this issue and addressed it as well (Sperber 2001). 


4. Future values 

A FRP event occurrence is a “future value”, or simply “future”, 
i.e., a value and an associated time. To simplify the semantics and 
implementation of events, and to provide an abstraction that may 
have uses outside of FRP, let’s now focus on futures. Semantically, 

type F a = (T, a) 
force :: Future a —> F a 

Like events and behaviors, much of the interface for future 
values is packaged as instances of standard type classes. Moreover, 
as with behaviors, the semantics of these instances are defined as 
type class morphisms. The process of exploring these morphisms 
reveals requirements for the algebraic structure of T. 

4.1 Functor 

The semantic domain for futures, partially applied pairing, is a 
functor: 

instance Functor ((,) t) 

where fmap h (t, a) = (t, h a) 

The semantic function, force, is a functor morphism: 
instance se m Functor Future where 
force (fmap h u) = fmap h (force u) 

= (t, h a) where (t, a) = force u 
Thus, mapping a function over a future gives a future with the same 
time but a transformed value. 

4.2 Applicative functor 

For applicative functors, the semantic instance (pairing) requires an 
additional constraint: 

instance Monoid t =>■ Applicative ((,) t) where 
pure a = (0, a) 

(t,f) <*> (t',x) = (t © t'J x) 

When t is a future time, what meanings do we want for 0 
and (©)? Two future values can be combined only when both are 
known, so (©) = max. Since 0 is an identity for (©), it follows 
that 0 = minBound, and so T must have a least element. 

The Applicative semantics for futures follow from these con¬ 
siderations choosing force to be an applicative functor morphism: 
instance S em Applicative Future where 


force (pure a) 

— pure a 


;€(«• "> 


= (minBound, a) 

force (uf <*> u x 

) = force Uf <*> force 


= (tx,x) 


= (if ®t x ,f x) 


= (i f ‘max‘i x ,f x) 


where 


(i/,f) = force u f 
(i x , x) = force u x 

Now, of course these definitions of (©) and 0 do not hold 
for arbitrary t, even for ordered types, so the pairing instance of 
Applicative provides helpful clues about the algebraic structure of 

Alternatively, for a relative-time semantics, use the Sum monoid 
in place of the Max monoid. 

4.3 Monad 

Given the Monoid constraint on t, the type constructor ((,) f) is 
equivalent to the more familiar writer monad. 



instance Monoid t => Monad ((,) t) where 
return a = (0, a) 

(t a , a) 3= h = (t a ® t b , b) 
where (tb,b) = h a 

Taking force to be a monad morphism (Wadler 1990), 
instance sem Monad Future where 
force (return a ) = return a 

= (minBound , a) 

force (u :»= fc) = force u >= /orce o k 
= (t a ‘max' U, b) 
where ( t a , a) = force u 

(tb, b ) = force (k a) 

Similarly, join collapses a future future into a future. 

join F :: Future (Future a) —> Future a 

force (join F uu) = join (fmap force (force uu)) 

= (in ‘max 1 t a , a) 
where (t u , u) = force uu 
(t a , a) = force u 

So, the value of the join is the value of the of the inner future, and 
the time matches the later of the outer and inner futures. (Alterna¬ 
tively, the sum of the future times, in relative-time semantics.) 

4.4 Monoid 

A useful (©) for futures simply chooses the earlier one. Then, as 
an identity for (©), 0 must be the future that never arrives. (So T 
must have an upper bound.) 

instance S em Monoid (Future a ) where 
force 0 = (maxBound, _L) 
force (u a © Ub) = if t a ^ tb then u a else Ub 
where 

(ta, -) = force Ua 
(tb, -) — force Ub 

(This definition does not correspond to the standard monoid in¬ 
stance on pairs, so force is not a monoid morphism.) 

Note that this Monoid instance (for future values) uses maxBound 
and min , while the Monoid instance on future times uses minBound 

4.5 Implementing futures 

The semantics of futures can also be used as an implementation, 
if the type of future times, FTime (with meaning T), satisfies the 
properties encountered above: 

• Ordered and bounded with lower and upper bounds of — oo and 
oo (i.e., before and after all sample times), respectively. 

• A monoid, in which 0 = —oo and (©) = max. 

• To be useful, the representation must reveal partial information 
about times (specifically lower bounds), so that time compar¬ 
isons can complete even when one of the two times is not yet 
fully known. 

Assuming these three properties for FTime, the implementa¬ 
tion of futures is easy, with most of the functionality derived (using 
a GHC language extension) from the pairing instances above, 
newtype Future a = Fut (FTime, a) 
deriving (Functor, Applicative, Monad) 

A Monoid instance also follows directly from the semantics in 
Section 4.4: 


instance Monoid (Future a) where 
0 = Fut (maxBound, _L) 

— problematic: 

U a @(Fut (t a , -)) © Ub@(Fut (tb, _)) = 

if t a ^ tb then u a else Ub 

This definition of (©) has a subtle, but important, problem. 
Consider computing the earliest of three futures, (u a © Ub) © u c , 
and suppose that u c is earliest, so that t c < t a ‘min' tb. No matter 
what the representation of FTime is, the definition of (©) above 
cannot produce any information about the time of u a © Ut, until 
t a ^ h is determined. That test will usually be unanswerable until 
the earlier of those times arrives, i.e., until t a ‘min' tb, which (as 
we’ve supposed) is after f c . 

To solve this problem, change the definition of (©) on futures 
to immediately yield a time as the (lazily evaluated) min of the two 
future times. Because min yields an FTime instead of a boolean, 
it can produce partial information about its answer from partial 
information about its inputs. 

— working definition: 

Fut (t a , a) © Fut (tb, b) = 

Fut (t a ‘min' tb, if t a ^ tb then a else b) 

This new definition requires two comparison-like operations in¬ 
stead of one. It can be further improved by adding a single oper¬ 
ation on future times that efficiently combines min and (^). 

4.6 Future times 

Each of the three required properties of FTime (listed in Sec¬ 
tion 4.5) can be layered onto an existing type: 

type FTime = Max (AddBounds (Improving Time)) 

The Max wrapper adds the required monoid instance while 
inheriting Ord and Bounded. 

newtype Max a = Max a deriving (Eq, Ord, Bounded) 
instance (Ord a, Bounded a) => Monoid (Max a) where 
0 = Max minBound 

Max a © Max b = Max (a ‘max' b) 

The AddBounds wrapper adds new least and greatest elements, 
preserving the existing ordering. 

data AddBounds a = 

MinBound \ NoBound a \ MaxBound deriving Eq 
instance Bounded (AddBounds a) where 
minBound = MinBound 
maxBound = MaxBound 

For an unfortunate technical reason, AddBounds does not derive 
Ord. The semantics of Haskell’s deriving clause does not guar¬ 
antee that min is defined in terms of min on the component types. 
If min is instead defined via (€) (as currently in GHC), then par¬ 
tial information in the type parameter a cannot get passed through 
min. For this reason, AddBounds has an explicit Ord instance, 
given in part in Figure 1. 

The final wrapper. Improving, is described in Section 9. It adds 
partial information to times and has min and (^) that work with 
partially known values. 

5. Reactive normal form 

FRP’s behavior and event combinators are very flexible. For in¬ 
stance, in bo ‘switcher ‘ e, the phases (bo, ...) themselves may be 
reactive, either as made by switcher, or by fmap or (<*>) ap¬ 
plied to reactive behaviors. This flexibility is no trouble at all for 




instance Ord a => Ord (AddBounds a) where 
MinBound ‘min‘ _ = MinBound 

‘min' MinBound = MinBound 
NoBound a ‘min' NoBound b = NoBound (a ‘min' b) 
u 'min' MaxBound = u 

MaxBound ‘min' v = v 

— similarly for (^) and max 


Figure 1. Ord instance for the AddBounds type 


the function-based semantics in Section 2, but how can we find our 
way to an efficient, data-driven implementation? 

Observed over time, a reactive behavior consists of a sequence 
of non-reactive phases, punctuated by events. Suppose behaviors 
can be viewed or represented in a form that reveals this phase struc¬ 
ture explicitly. Then monotonic behavior sampling could be imple¬ 
mented efficiently by stepping forward through this sequence, sam¬ 
pling each phase until the next one begins. For constant phases (a 
common case), sampling would then be driven entirely by relevant 
event occurrences. 

Definition: A behavior-valued expression is in reactive normal 
form (RNF) if it has the form b 'switcher' e, where the lead 
behavior b is non-reactive, i.e., has no embedded switcher (or 
combinators defined via switcher), and the behaviors in e are also 
in RNF. 

For instance, b can be built up from pure, time, fmap, and 
(<*>). To convert arbitrary behavior expressions into RNF, one 
can provide equational rewrite rules that move switcher s out of 
switcher heads, out of fmap, (<*>), etc, and prove the correctness 
of these equations from the semantics in Section 2. For example, 

fmap f (b ‘switcher' e) = fmap f b ‘switcher‘ fmap f e 

The rest of this paper follows a somewhat different path, inspired 
by this rewriting idea, defining an RNF-based representation. 

5.1 Decoupling discrete and continuous change 

FRP makes a fundamental, type-level distinction between events 
and behaviors, i.e., between discrete and continuous. Well, not 
quite. Although (reactive) behaviors are defined over continuous 
time, they are not necessarily continuous. For instance, a behavior 
that counts key-presses changes only discretely. Let’s further tease 
apart the discrete and continuous aspects of behaviors into two 
separate types. Call the purely discrete part a “reactive value” and 
the continuous part a “time function”. FRP’s notion of reactive 
behavior decomposes neatly into these two simpler notions. 

Recall from Section 1 that continuous time is one of the reasons 
for choosing pull-based evaluation, despite the typical inefficiency 
relative to push-based. As we will see, reactive values can be eval¬ 
uated in push style, leaving pull for time functions. Recomposing 
reactive values and time functions yields an RNF representation 
for reactive behaviors that reveals their phase structure. The two 
separate evaluation strategies combine to produce an efficient and 
simple hybrid strategy. 

5.2 Reactive values 

A reactive value is like a reactive behavior but is restricted to 
changing discretely. Its meaning is a step function, which is fully 
defined by its initial value and discrete changes, with each change 
defined by a time and a value. Together, these changes correspond 
exactly to a FRP event, suggesting a simple representation: 

data Reactive a = a ‘Stepper' Event a 


The meaning of a reactive value is given via translation into a 
reactive behavior, using stepper: 
rat :: Reactive a —> B a 
rat (ao ‘ Stepper‘ e ) = at (ao ‘ stepper' e) 

= Xt —► last (ao : before (occs e) t) 
where before is as defined in Section 2.3. 

With the exception of time, all behavior operations in Section 2 
(as well as others not mentioned there) produce discretely-changing 
behaviors when given discretely-changing behaviors. Therefore, all 
of these operations (excluding time) have direct counterparts for 
reactive values. In addition, reactive values form a monad. 
stepper R :: a —► Event a —> Reactive a 
switches :: Reactive a —► Event (Reactive a ) 

—* Reactive a 

instance Functor Reactive 
instance Applicative Reactive 
instance Monad Reactive 

The semantic function, rat, is a morphism on Functor, Applicative, 
and Monad: 

instance sem Functor Reactive where 
rat (fmap f b) = fmap f (rat b) 

instance S em Applicative Reactive where 
rat (pure a) = pure a 
= const a 

rat (rf <*> rMmj rat rj <*> rat r x 

= Xt —> (rf 'rat't) (r x 'rat't) 
instance S em Monad Reactive where 
rat (return a) = return a 
= const a 

rat (r k) = rat r >= rat o k 

= Xt —> (rat o k) (rat r t) t 
= Xt —> rat (k (rat r t )) t 

The join operation may be a bit easier to follow than (»=). 
rat (join R rr) = join (fmap rat (rat r)) 

= join (rat o rat rr) 

= Xt —> rat (rat rr t) t 

Sampling join R rr at time t then amounts to sampling rr at t to 
get a reactive value r, which is itself sampled at t. 

5.3 Time functions 

Between event occurrences, a reactive behavior follows a non¬ 
reactive function of time. Such a time function is most directly and 
simply represented literally as a function. However, functions are 
opaque at run-time, preventing optimizations. Constant functions 
are particularly helpful to recognize, in order to perform dynamic 
constant propagation, as in (Elliott 1998a; Nilsson 2005). A simple 
data type suffices for recognizing constants. 

data Fun t a = K a \ Fun (t — h a) 

The semantics is given by a function that applies a Fun to an 
argument. All other functionality can be neatly packaged, again, in 
instances of standard type classes, as shown in Figure 2. There is a 
similar instance for Arrow as well. The semantic function, apply, 
is a morphism with respect to each of these classes. 

Other optimizations could be enabled by in a similar way. For 
instance, generalize the K constructor to polynomials (adding a 
Num constraint for /,). Such a representation could support pre¬ 
cise and efficient differentiation and integration and prediction of 






data Fun t a = K a \ Fun (t —> a) 
apply :: Fun t a —> (f —> a) — semantic function 
apply ( K a) = const a 
apply (Fun f) = f 
instance Functor (Fun t) where 
fmapf(Ka) =K (fa) 

fmap f (Fun g) = Fun (f o g) 
instance Applicative (Fun t) where 
pure = K 

K f <*> K x =K (f x) 

cf <*> cx = Fun (apply cf <*> apply cx) 
instance Monad (Fun t) where 
return = pure 

K a 3= h = h a 

Fun f h = Fun (f apply o h) 


Figure 2. Constant-optimized functions 


some synthetic events based on root-finding (e.g., some object col¬ 
lisions). The opacity of the function arguments used with fmap and 
arr would, however, limit analysis. 

5.4 Composing 

Reactive values capture the purely discrete aspect of reactive be¬ 
haviors, while time functions capture the purely continuous. Com¬ 
bining them yields a representation for reactive behaviors. 

type Behavior = Reactive o Fun Time 
Type composition can be defined as follows: 
newtype (ho g) a = O (h (g a)) 

Functors compose into functors, and applicative functors into 
applicative functors (McBride and Paterson 2008). 

instance (Functor h, Functor g) 

=> Functor (h o g) where 
fmap f (O hga) = O (fmap (fmap f) hga) 
instance (Applicative h, Applicative g) 

=> Applicative (h o g) where 
pure a = O (pure (pure a)) 

O hgf <*> O hgx = O (liftA 2 (<*>) hgf hgx) 

The semantics of behaviors combines the semantics of its two 
components. 

at :: Behavior a —» B a 

at (Or/) = join (fmap apply (rat r/)) 

= Xt —> apply (rat rf t) t 
More explicitly, 

O (f ‘ Stepper 1 e) ‘at‘ t = last (f : before (occs e) t ) t 

This last form is almost identical to the semantics of switcher in 
Section 2.3. 

This representation of behaviors encodes reactive normal form, 
but how expressive is it? Are all of the Behavior combinators 
covered, or do some stray outside of RNF? 

The time combinator is non-reactive, i.e., purely a function of 
time: 

time = O (pure (Fun id)) 


The Functor and Applicative instances are provided automati¬ 
cally from the instances for type composition (above), given the in¬ 
stances for Reactive and Fun (specified in Section 5 and to be de¬ 
fined in Section 7). Straightforward but tedious calculations show 
that time and the Functor and Applicative instances have the se¬ 
mantics specified in Section 2. 

I doubt that there is a Monad instance. While the semantic do¬ 
main B is a monad, I think its join surpasses the meanings that can 
be represented as reactive time functions. For purely discrete ap¬ 
plications, however, reactive behaviors can be replaced by reactive 
values, including the Monad functionality. 

6. Another angle on events 

The model of events we’ve been working with so far is time- 
ordered lists of future values, where a future value is a time/value 
pair: [(fo, oo), (ti, ai),...]. If such an occurrence fist is nonempty, 
another view on it is as a time to, together with a reactive value 
having initial value ao and event with occurrences [(ti, ai ),...]. If 
the occurrence list is empty, then we could consider it to have initial 
time oo ( maxBound ), and reactive value of _L. Since a future value 
is a time and value, it follows that an event (empty or nonempty) 
has the same content as a future reactive value. This insight leads 
to a new representation of functional events: 

— for non-decreasing times 
newtype Event a = Ev (Future (Reactive a)) 

With this representation, the semantic function on events peels off 
one time and value at a time. 

occs :: Event a —> E a 

occs (Ev (Fut (oo, _ ))) = [] 

occs (Ev (Fut (t a , a ‘Stepper ‘ e'))) = (t a , a) : occs e' 

Why use this representation of events instead of directly mim¬ 
icking the semantic model El The future-reactive representation 
will be convenient in defined Applicative and Monad instances 
below. It also avoids a subtle problem similar to the issue of com¬ 
paring future times using (^), discussed in Section 4.5. The defini¬ 
tion of merge in Section 2.2.1 determines that an event has no more 
occurrences by testing the list for emptiness. Consider filtering out 
some occurrences of an event e. Because the emptiness test yields a 
boolean value, it cannot yield partial information, and will have to 
block until the prefiltered occurrences are known and tested. These 
issues are also noted in Sperber (2001). 

7. Implementing operations on reactive values 
and events 

The representations of reactive values and events are now tightly 
interrelated: 

data Reactive a = a 1 Stepper 1 Event a 
newtype Event a = Ev (Future (Reactive a)) 

These definitions, together with Section 5, make a convenient basis 
for implementing FRR 

7.1 Reactive values 

7.1.1 Functor 

As usual, fmap f applies a function / to a reactive value pointwise, 
which is equivalent to applying / to the initial value and to each 
occurrence value. 

instance Functor Reactive where 
fmap f (a ‘ Stepper ‘ e) = f a ‘ Stepper ‘ fmap f e 




7.1.2 Applicative 

The Functor definition was straightforward, because the Stepper 
structure is easily preserved. Applicative is more challenging, 
instance Applicative Reactive where ... 

First the easy part. A pure value becomes reactive by using it as the 
initial value and 0 as the (never-occuring) change event: 

pure a = a 1 Stepper 1 0 

Consider next applying a reactive function to a reactive argument: 

r/@(/ ‘ Stepper ‘ Ev Uf) <*> r x @(x l Stepper‘ Ev u x } = 
f x 1 Stepper 1 Ev u 

where u = ... 

The initial value is / x, and the change event occurs each time 
either the function or the argument changes. If the function changes 
first, then (at that future time) apply a new reactive function to an 
old reactive argument: 

fmap (A rp —+ rf <*> r x ) Uf 

Similarly, if the argument changes first, apply an old reactive func¬ 
tion and a new reactive argument: 

fmap (A r x > —> rf <*> r x i) u x 
Combining these two futures as alternatives: 6 

u = fmap (\rp —+ rp <*> r x ) Uf © 
fmap (A r x i —> rf <*> r x >) u x 

More succinctly, 

u = (( <£>r x ) <£> Uf) © ((r/<*>) <$> u x ) 

A wonderful thing about this (<*>) definition for Reactive is 
that it automatically reuses the previous value of the function or 
argument when the argument or function changes. This caching 
property is especially handy in nested applications of (<*>), which 
can arise either explicitly or through liftA 2 , liftA 3 , etc. Consider 
u = liftA 2 f r s or, equivalently, u = (/ <$>r)<*>.s, where r and 
s are reactive values, with initial values ro and so, respectively. The 
initial value «o of m is / ro so. If r changes from ro to n, then the 
new value of / <$> r will be / n, which then gets applied to so, i.e., 
in e/ n so. If instead s changes from so to si, then ui = / ro si. 
In this latter case, the old value / ro of / <$> r is passed on without 
having to be recomputed. The savings is significant for functions 
that do some work based on partial applications. 

7.1.3 Monad 

The Monad instance is perhaps most easily understood via its join: 

join R :: Reactive (Reactive a) —> Reactive a 
The definition of join R is similar to (<*>) above: 

join R ((a ‘ Stepper ‘ Ev tv) ‘Stepper 1 Ev 
a ‘ Stepper ‘ Ev u 

where u = ... 

Either the inner future (tv) or the outer future (u rr ) will arrive first. 
If the inner arrives first, switch and continue waiting for the outer: 

(‘ switcher 1 Ev u^) <$> tv 

The (<$>) here is over futures. If instead the outer future arrives 
first, abandon the inner and get new reactive values from the outer: 


6 Recall from Section 4.1 that fmap f u arrives exactly when the future u 
arrives, so the (®)’s choice in this case depends only on the relative timing 
of Uf and u x . 


join <$> Urr 

Choose whichever comes first: 

u = ((‘ switcher 1 Ev u rr ) <$> tv) © ( join <S> Urr) 

Then plug this join into a standard Monad instance: 
instance Monad Reactive where 
return = pure 
r ~^= h = join R (fmap h r) 

7.1.4 Reactivity 

In Section 2.3, stepper (on behaviors) is defined via switcher. For 
reactive values, stepper R corresponds to the Stepper constructor: 
stepper R :: a —> Event a —> Reactive a 
stepper R = Stepper 

The more general switching form can be expressed in terms of 
stepper R and monadic join: 

switcherR :: Reactive a —> Event (Reactive a) 

—> Reactive a 

r ‘ switcherR ‘ e r = join R (r ‘ stepper R e r ) 

7.2 Events 

7.2.1 Functor 

The Event functor is also easily defined. Since an event is a future 
reactive value, combine fmap on Future with fmap on Reactive. 
instance Functor Event where 
fmap f (Ev u) = Ev (fmap (fmap f) u) 

7.2.2 Monad 

Assuming a suitable join for events, the Monad instance is simple: 
instance Monad Event where 
return a = Ev (return (return a)) 
r ^= h = join E (fmap h r) 

This definition of return makes a regular value into an event by 
making a constant reactive value ( return ) and wrapping it up as an 
always-available future value (return). 

The join operation collapses an event-valued event ee into an 
event. Each occurrence of ee delivers a new event, all of which get 
adjusted to insure temporal monotonicity and merged together into 
a single event. The event ee can have infinitely many occurrences, 
each of which (being an event) can also have an infinite number of 
occurrences. Thus join E has the tricky task of merging (a repre¬ 
sentation of) a sorted infinite stream of sorted infinite streams into 
a single sorted infinite stream. Since an event is represented as a 
Future, the join makes essential use of the Future monad 7 : 
join E :: Event (Event a) —> Event a 
join E (Event u) = Event (u »= eFuture o g) 
where 

g (e ‘Stepper ‘ ee) = e © join E ee 
eFuture (Ev w);' ■== u 

7.2.3 Monoid 

The Monoid instance relies on operations on futures: 
instance Ord t => Monoid (Event a ) where 
0 = Ev 0 

Ev « © Ev v = Ev (u l merge u ‘ v) 


7 This definition is inspired by one from Jules Bean. 



The never-occuring event happens in the never-arriving future. 

To merge two future reactive values u and v, there are again two 
possibilities. If u arrives first (or simultaneously), with value ao and 
next future u', then ao will be the initial value and v! l merge u ‘ v 
will be the next future. If v arrives first, with value bo and next 
future v', then bo will be the initial value and u l merge u ‘ v' will be 
the next future. 

merge u :: Future (Reactive a ) —> Future (Reactive a) 

—► Future (Reactive a) 
u ‘merge u ‘ v = (inFutR ( ‘merge‘v ) <$> u) ® 

(inFutR (Emerge 1 ’) <$> v) 

where 

inFutR f (r 1 Stepper' Ev u 1 ) = r 1 Stepper 1 Ev (/ «') 

8. Monotonic sampling 

The semantics of a behavior is a function of time. That function 
can be applied to time values in any order. Recall in the seman¬ 
tics of switcher (Section 2.3) that sampling at a time t involves 
searching through an event for the last occurrence before t. The 
more occurrences take place before t, the costlier the search. Lazy 
evaluation can delay computing occurrences before they’re used, 
but once computed, these occurrences would remain in the events, 
wasting space to hold and time to search. 

In practice, behaviors are rendered forward in time, and so are 
sampled with monotonically increasing times. Making this usage 
pattern explicit allows for much more efficient sampling. 

First, let’s consider reactive values and events. Assume we have 
a consumer for generated values: 
type Sink a = a —* 10 () 

For instance, a sink may render a number to a GUI widget or 
an image to a display window. The functions sinkR and sinks 
consume values as generated by events and reactive values: 
sinkR :: Sink a —* Reactive a —> 10 b 
sinkE :: Sink a —> Event a —> 10 b 

The implementation is an extremely simple back-and-forth, with 
sinkR rendering initial values and sinkE waiting until the next 
event occurrence. 

sinkR snk (a ‘ Stepper ‘ e) = snk a sinkE snk e 

sinkE snk (Ev (Fut ( t r , r))) = waitFor t r sinkR snk r 
Except in the case of a predictable event (such as a timer), 
waitFor t r blocks simply in evaluating the time t r of a future 
event occurrence. Then when evaluation of t r unblocks, the real 
time is (very slightly past) t r , so the actual waitFor need not do 
any additional waiting. 

A behavior contains a reactive value whose values are time 
functions, so it can be rendered using sinkR if we can come up 
with a appropriate sink for time functions. 
sinks :: Sink a —> Behavior a —> 10 b 
sinks snk (O r/) = do snkF <— newTFunSink snk 
sinkR snkF rf 

The procedure newTFunSink makes a sink that consumes suc¬ 
cessive time functions. For each consumed constant function K a, 
the value a is rendered just once (with snk). When a non-constant 
function Fun f is consumed, a thread is started that repeatedly 
samples / at the current time and renders: 

forklO (forever (/ <$> getTime = snk)) 

In either case, the constructed sink begins by killing the current 
rendering thread, if any. Many variations are possible, such as using 


a GUI toolkit’s idle event instead of a thread, which has the benefit 
of working with thread-unsafe libraries. 

9. Improving values 

The effectiveness of future values, as defined in Section 4, depends 
on a type wrapper Improving, which adds partial information in 
the form of lower bounds. This information allows a time compar¬ 
ison t a ^ 4 to suceed when the earlier of t a and It, arrives instead 
of the later. It also allows 4 ‘mm‘4 to start producing lower bound 
information before either of l„ and tb is known precisely. 

Fortunately, exactly this notion was invented, in a more gen¬ 
eral setting, by Warren Burton. “Improving values” (Burton 1989, 
1991) provide a high-level abstraction for parallel functional pro¬ 
gramming with determinate semantics. 

An improving value (IV) can be represented as a list of lower 
bounds, ending in the exact value. An IV representing a simple 
value (the exactly function used in Section 4.6), is a singleton list 
(no lower bounds). See (Burton 1991, Figure 3) for details. 

Of course the real value of the abstraction comes from the 
presence of lower bounds. Sometimes those bounds come from 
max, but for future times, the bounds will come to be known over 
time. One possible implementation of future times would involve 
Concurrent Haskell channels (Peyton Jones et al. 1996). 

getChanContents :: Chan a —> 10 [a] 

The idea is to make a channel, invoke getChanContents, and wrap 
the result as an IV. Later, lower bounds and (finally) an exact value 
are written into the channel. When a thread attempts to look beyond 
the most recent lower bound, it blocks. For this reason, this simple 
implementation of improving values must be supplied with a steady 
stream of lower bounds, which in the setting of FRP correspond to 
event non-occurrences. 

Generating and manipulating numerous lower bounds is a sig¬ 
nificant performance drawback in the purely functional implemen¬ 
tation of IVs. A more efficient implementation, developed next, 
thus benefits FRP and other uses of IVs. 

10. Improving on improving values 

In exploring how to improve over the functional implementation of 
improving values, let’s look at how future times are used. 

• Sampling a reactive value requires comparing a sample time t 
with a future time /?,./. 

• Choosing the earlier of two future values ((©) from Section 4), 
uses min and (s() on future times. 

Imagine that we can efficiently compare an improving value 
with an arbitrary known (exact) value: 8 

compare 7 :: Ord a => Improving a —> a —> Ordering 
How might we use compare, to compare two future times, e.g., 
testing t a ^ 4? We could either extract the exact time from 4 and 
compare it with tb, or extract the exact time from tb and compare 
it with t a - These two methods produce the same information but 
usually not at the same time, so let’s choose the one that can answer 
most promptly. If indeed 4 ^ 4, then the first method will likely 
succeed more promptly and otherwise the second method. The 
dilemma in choosing is that we have to know the answer before 
we can choose the best method for extracting that answer. 

Like many dilemmas, this one results from either/or thinking. 
A third alternative is to try both methods in parallel and just use 


8 The Haskell Ordering type contains LT, EQ, and GT to represent less- 
than, equal-to, and greater-than. 




whichever result arrives first. Assume for now the existence of an 
“unambiguous choice” operator, unamb, that will try two methods 
to solve a problem and return whichever one succeeds first. The two 
methods are required to agree when they both succeed, for semantic 
determinacy. Then 

t a ^tb = (( t a ‘compare / exact tb) ^ GT) ‘unamb 1 
((tb ‘compare/ exact t a ) ^ LT) 

Next consider i a ‘min‘ib. The exact value can be extracted from 
the exact values of t a and tb, or from (^) on IVs: 

exact (t a ‘min 1 tb) = exact t a ‘min‘ exact tb 

= exact (if (4 ^ 4) then t a else 4) 

How can we compute (t a ‘min‘tb)‘ compare j‘ t for an arbitrary 
exact value t? The answer is t a ‘compare / L if L a ^ 4 , and 
tb ‘ compare / t otherwise. However, this method, by itself, misses 
an important opportunity. Suppose both of these tests can yield 
answers before it’s possible to know whether t a ^ 4 - If the 
answers agree, then we can use that answer immediately, without 
waiting to learn whether t a ^ 4- 

With these considerations, a new representation for IVs suggests 
itself. Since the only two operations we need on IVs are exact 
and compare j, use those two operations as the IV representation. 
Figure 3 shows the details, with unamb and asAgree defined in 
Section 11. Combining (^) and min into minLE allows for a 
simple optimization of future ( 0 ) from Section 4.5. 

11. Unambiguous choice 

The representation of improving values in Section 10 relies on an 
“unambiguous choice” operator with determinate semantics and an 
underlying concurrent implementation. 

— precondition: compatible arguments 

unamb :: a —> a —> a 

In order to preserve simple, determinate semantics, unamb may 
only be applied to arguments that agree where defined. 

compatible a b = (a = L\/ b = LW a = b) 
unamb yields the more-defined of the two arguments. 

Va b.compatible a b => unamb a b = aU b 

Operationally, unamb forks two threads and evaluates one argu¬ 
ment in each. When one thread finishes its computed value is re- 

Figure 4 shows one way to implement unamb, in terms of an 
ambiguous choice operator, amb. The latter, having indeterminate 
(ambiguous) semantics, is in the 10 type, using race to run two 
concurrent threads. For inter-thread communication, the race func¬ 
tion uses a Concurrent Haskell MVar (Peyton Jones et al. 1996) to 
hold the computed value. Each thread tries to execute an action and 
write the resulting value into the shared MVar. The takeMVar op¬ 
eration blocks until one of the threads succeeds, after which both 
threads are killed (one perhaps redundantly). 9 This unamb imple¬ 
mentation fails to address an important efficiency concern. When 
one thread succeeds, there is no need to continue running its com¬ 
petitor. Moreover, the competitor may have spawned many other 
threads (due to nested unamb), all of which are contributing to¬ 
ward work that is no longer relevant. 

The assuming function makes a conditional strategy for com¬ 
puting a value. If the assumption is false, the conditional strat¬ 
egy yields _L via hang, which blocks a thread indefinitely, while 


9 My thanks to Spencer Janssen for help with this implementation. 


— An improving value. Invariant: 

— comparej iv □ compare (exact iv) 
data Improving a = 

Imp { exact:: a, compare 7 :: a —* Ordering} 
exactly :: Ord a => a —+ Improving a 
exactly a = Imp a (compare a) 
instance Eq a => Eq (Improving a) where 
Imp a - = Imp b _ = a = b 
instance Ord a => Ord (Improving a) where 
s ^ t = snd (s ‘minLE 1 t) 
s ‘min‘ t = fst (s ‘minLE 1 t ) 
s ‘max 1 t = fst (s ‘maxLE‘ t) 

— Efficient combination of min and (^) 
minLE :: Ord a => Improving a —> Improving a 

—> (Improving a, Bool) 

Imp u uComp ‘minLE 1 Imp v vComp = 

(Imp uMinV wComp,uLeqV) 
where 

uMinV = if uLeqV then u else v 

— u ^ v: Try u ‘ compare‘ v and v ‘ compare‘ u. 
uLeqV = (uComp v ^ GT) ‘unamb 1 (vComp u ^ LT) 
minComp = if uLeqV then uComp else vComp 

— (u ‘min‘ v) ‘ compare' t : Try comparing according to 

— whether u ^ v, or use either answer if they agree. 
wComp t = minComp t ‘unamb' 

(uComp t ‘asAgree‘ vComp t) 

— Efficient combination of max and (^) 
maxLE :: Ord a => Improving a —> Improving a 

—> (Improving a, Bool) 

— ... similarly ... 


Figure 3. Improved improving values 


consuming neglible resources and generating no error. One use of 
assuming is to define asAgree, which was used in Figure 3. 

12. Additional functionality 

All of the usual FRP functionality can be supported, including the 
following. 

Integration Numeric integration requires incremental sampling 
for efficiency, replacing the apply interface from Section 5.3 by 
applyK from Section 8. The residual time function returned by 
applyK remembers the previous sample time and value, so the next 
sampling can do a (usually) small number of integration steps. (For 
accuracy, it is often desirable to take more integration steps than 
samples.) Integration of reactive behaviors can work simply by in¬ 
tegrating each non-reactive phase (a time function) and accumu¬ 
lating the result, thanks the interval-additivity property of definite 
integration (£ f = f* f + f* /). 

Accumulation Integration is continuous accumulation on behav¬ 
iors. The combinators accumE and accumn discretely accumulate 
the results of event occurrences. 

accumR :: a —► Event (a —> a) —> Reactive a 

accumE a —> Event (a —> o) —> Event a 





— Unambiguous choice on compatible arguments. 
unamb :: a —> a —> a 

a ‘unamb 1 b = unsafePerformlO (a ‘amb‘ b) 

— Ambiguous choice, no precondition. 
amb :: a —> a —> 10 a 

a ‘amb‘ b = evaluate a ‘race‘ evaluate b 

— Race two actions in separate threads. 
race :: 10 a -> 10 a -> 10 a 

race :: 10 a -► 10 a 10 a 

a ‘race 1 b = 

do# <- newEmptyMVar 

t a <— forklO (a »= putMVar v) 
tb <— forklO (6 »= putMVar v) 
x <— takeMVar v 
return x 

— Yield a value if a condition is true. 
assuming :: Bool —> a —> a 

assuming c a = if c then a else bottom 

— The value of agreeing values (or bottom) 
asAgree :: Eq a => a —*• a —> a 

a ‘asAgree 1 b «= assuming (a = b) a 

— Never yield an answer. Identity for unamb. 
bottom :: a 

bottom = unsafePerformlO hanglO 

— Block forever, cheaply 
hanglO w 10 a 

hanglO = do forever (threadDelay maxBound) 
return _L 


Figure 4. Reference (inefficient) unamb implementation 

Each occurrence of the event argument yields a function to be 
applied to the accumulated value. 

a ‘accumR e = a ‘stepper‘ (a ‘ accumE ‘ e) 
a 'accumE‘ Ev Ur = Ev (h <S> Ur) 

where 

h (/ ‘Stepper' e') = f a ‘accumR e' 

Filtering It’s often useful to filter event occurrences, keeping 
some occurrences and dropping others. The Event monad instance 
allows a new, simple and very general definition that includes 
event filtering as a special case. One general filtering tool con¬ 
sumes Maybe values, dropping each Nothing and unwrapping 
each Just. 10 

joinMaybes :: MonadPlus m=$> m (Maybe a) —> m a 
joinMaybes = (f^=maybe mzero return) 

The MonadPlus instance for Event uses mzero = 0 and 
mplus as I©). The more common FRP event filter has the fol¬ 
lowing simple generalization: 

filter mp :: MonadPlus to => (a —> Bool ) —> to a —> m a 
filter mp p m = joinMaybes (liftM f to) 

where 

/ a | p a = Just a 

| otherwise = Nothing 


10 My thanks to Cale Gibbard for this succinct formulation. 


13. Related work 

The most closely related FRP implementation is the one underlying 
the Lula system for design and control of lighting, by Mike Sper- 
ber (2001). Like the work described above, Lula-FRP eliminated 
the overhead of creating and processing the large numbers of event 
non-occurrences that have been present, in various guises, in al¬ 
most all other FRP implementations. Mike noted that the pull-based 
event interface that motivates these non-occurrences also imposes a 
reaction latency bounded by the polling frequency, which detracts 
noticeably from the user experience. To eliminate non-occurrences 
and the resulting overhead and latency, he examined and addressed 
subtle issues of events and thread blocking, corresponding to the 
those discussed in Section 4.5. Mike’s solution, like the one de¬ 
scribed in Section 10 above, involved a multi-threaded implemen¬ 
tation. However, it did not guarantee semantic determinism, in case 
of simultaneous or nearly-simultaneous event occurrences. The im¬ 
plementation of event operations was rather complex, especially for 
event merging. The supporting abstractions used above (future val¬ 
ues, improving values, and unambiguous choice) seem to be helpful 
in taming that complexity. Lula-FRP’s behaviors still used a pure 
pull interface, so the latency solution was limited to direct use of 
events rather than reactive behaviors. The reactive value abstrac¬ 
tion used above allows behavior reactions at much lower latency 
than the sampling period. Unlike most published FRP implemen¬ 
tations, Lula-FRP was implemented in a strict language (Scheme). 
For that reason, it explicitly managed details of laziness left implicit 
in Haskell-based implementations. 

“Event-Driven FRP” (E-FRP) (Wan et al. 2002) also has similar 
goals. It focused on event-driven systems, i.e., ones in which lim¬ 
ited work is done in reaction to an event, while most FRP imple¬ 
mentations repeatedly re-evaluate the whole system, whether or not 
there are relevant changes. Like RT-FRP (Wan et al. 2001), expres¬ 
siveness is restricted in order to make guarantees about resource- 
bounded execution. The original FRP model of continuous time is 
replaced by a discrete model. Another restriction compared with 
the semantics of the original FRP (preserved in this paper) is that 
events are not allowed to occur simultaneously. 

Peterson et al. (2000) explored opportunities for parallelism in 
implementing a variation of FRP. While the underlying semantic 
model was not spelled out, it seems that semantic determinacy was 
not preserved, in contrast to the semantically determinate concur¬ 
rency used in this paper (Section 11). 

Nilsson (2005) presented another approach to FRP optimiza¬ 
tion. The key idea was to recognize and efficiently handle several 
FRP combinator patterns. In some cases, the standard Haskell type 
system was inadequate to capture and exploit these patterns, but 
generalized algebraic data types (GADTs) were sufficient. These 
optimizations proved worthwhile, though they did introduce signif¬ 
icant overhead in run-time (pattern matching) and code complexity. 
In contrast, the approach described in the present paper uses very 
simple representations and unadventurous, Hindley-Milner types. 
Another considerable difference is that (Nilsson 2005) uses an 
arrow-based formulation of FRP, as in Fruit (Courtney and Elliott 
2001) and Yampa (Nilsson et al. 2002). The nature of the Arrow 
interface is problematic for the goal of minimal re-evaluation. Input 
events and behaviors get combined into a single input, which then 
changes whenever any component changes. Moreover, because the 
implementation style was demand-driven, event latency was still 
tied to sampling rate. 

FranTk is a GUI library containing FRP concepts but mixing in 
some imperative semantics (Sage 2000). Its implementation was 
based on an experimental data-driven FRP implementation (El¬ 
liott 1998b), which was itself inspired by Pidgets++ (Scholz and 
Bokowski 1996). Pidgets-H- used functional values interactively re¬ 
computed in a data-driven manner via one-way constraints. None 



of these three systems supported continuous time, nor implemented 
a pure FRP semantics. 

At first blush, one might think that an imperative implementa¬ 
tion could accomplish what we set out to do in this paper. For in¬ 
stance, there could be imperative call-backs associated with meth¬ 
ods that side-effect some sort of dependency graph. As far as I 
know, no such implementation has achieved (nor probably could 
achieve) FRP’s (determinate) merge semantics for ordered receipt 
of simultaneous occurrences (which happens easily with composi¬ 
tional events) or even nearly-simultaneous occurrences. Imperative 
implementations are quite distant from semantics, hence hard to 
verify or trust. In contrast, the functional implementation in this 
paper evolves from the semantics. 

In some formulations of FRP, simultaneous occurrences are 
eliminated or merged (Nilsson et al. 2002; Wan and Hudak 2000; 
Wan et al. 2001), while this paper retains such occurrences as dis¬ 
tinct. In some cases, the elimination or merging was motivated by 
a desire to reduce behaviors and events to a single notion. This 
desire is particularly compelling in the arrow-based FRP formu¬ 
lations, which replace behaviors (or “signals”) and events with a 
higher level abstraction of “signal transformers”. Although simul¬ 
taneity is very unlikely for (distinct) purely physical events, it can 
easily happen with FRP’s compositional events. 

14. Future work 

• Much more testing, measurement, and tuning is needed in order 
to pragmatically and quantitatively evaluate the implementation 
techniques described in this paper, especially the new imple¬ 
mentation of improving values described in Section 10. How 
well do the techniques work in a complex application? 

• Can these ideas be transplanted to arrow-based formulations 
of FRP? How can changes from separately-changing inputs be 
kept from triggering unnecessary computation, when the arrow 
formulations seem to require combining all inputs into a single 
varying value? 

• Explore other uses of the unambiguous choice operator defined 
in Section 11, and study its performance, including the kinds 
of parallel search algorithms for which improving values were 
invented (Burton 1989, 1991). 

• Experiment with relaxing the assumption of temporal mono¬ 
tonicity exploited in Section 8. For instance, a zipper represen¬ 
tation for bidirectional sampling could allow efficient access to 
nearby past event occurrences as well as future ones. Such a 
representation may be efficient in time though leaky in space. 

• Type class morphisms are used to define the the semantics 
of every key type in this paper except for events. Can this 
exception be eliminated? 

• Since reactive values are purely data, they cache “for free”. 
In contrast, time functions (Section 5.3) have a partly function 
representation. Is there an efficiently caching representation? 
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